NetLogo User Community Models

(back to the NetLogo User Community Models)

Download If clicking does not initiate a download, try right clicking or control clicking and choosing "Save" or "Download".(The run link is disabled for this model because it was made in a version prior to NetLogo 6.0, which NetLogo Web requires.)

WHAT IS IT?

This is a geospatial model of the dynamics within a sushi restaurant built in order to demonstrate several key notions related to complexity theory. It additionally analyses the multiple relationships between the different systems involved allowing the observer to find an optimal system for serving customers while keeping angry customer to a minimum. Though being less abstract than most this model could potentially be useful commercially in increasing restaurant efficiency it should mainly be seen as an educational aid as the simplifications make it unrealistic.

HOW IT WORKS

There are several systems and agents involved in this complex model.

The customer:
Customers are randomly generated at different arrival spawn points based on the customer-chance variable. They make their way to the entrance where they must queue to progress into the restaurant. Upon entering the restaurant the customer chooses a seat and begins waiting for their desired dish to arrive on the conveyor belt. The dish the customer chooses is based on the user-defined demand for each dish, chosen randomly using probability. Once the dish appears in front of them they take it and begin eating. Once they have finished eating they leave their seat, move towards the exit and leave the restaurant and model.
There are also reflexive systems in place: If the customer has to queue for too long upon arrival they will become angry and leave the model. If the customer has to wait too long for their desired dish they will become angry and leave the restaurant and model.

The chefs:
The number of chefs is defined by the user before setup but their initial location is randomly generated within the kitchen. The chef's progress through a cycle of dish prepariation. Initially the chef picks a dish to make; this is based on user-defined supply values for each dish. The chef must then collect all the ingredients for that dish before the agent can prepare it. There are four dishes which progress in complexity, the required ingredients are:

Tuna Sushi: Tuna, Nori, Soy Sauce, Rice
Salmon Sushi: Salmon, Rice, Nori
Soya Steak: Beef, Soy Sauce
Calamari: Squid

Once the ingredients are collected the chef moves to a counter and begins preparing the dish. Each dish takes a different amount of time to prepare (defined within the source code). Once the dish has been prepared the chef moves to the service area and places it on the conveyor belt. The chef then restarts the cycle.

Additionally there is an option to enable reflexive creation of dishes which uses information on the amount of different types of dishes in order to generate the supply values. This reduces the chance of an over-production of dishes which can lead to bottlenecks etc.

The food:
Once a dish is created it progresses along the conveyor belt, multiple dishes cannot be placed in the same patch so the conveyor belt can become full. The speed of the belt can be altered as the model is running

The doorman:
When all the seats in the restaurant are full the doormen block the entrance preventing more customers flooding the restaurant, this causes a queue to form. There is an additional option for the observer to close the doors allowing the dynamics to change as the model is running

Movement:
A new underlying infrastructure of movement was written for this model in order to create a probabilistic yet logical movement of people round the model. It was designed to be operated within a cellular environment and avoid common issues such as an agent moving at angles travelling through a separate patch to get to the patch in front of it.

This system of movement only allows agents to move horizontally and vertically, the agent has a destination patch and its route is probabilistically based on the relative x and y lengths. I.e. if a patch is further north then it is east the agent is more likely to move north but may still move east. This system is similar to how real human decisions are made.

Collision avoidance is also built into this system.

HOW TO USE IT

The only interface variable which the observer must set before the model has run is the number of chefs. All other variables can be changed on the fly allowing dynamic observation. Once the numbers of chefs are set the user should press setup followed by go

Additional variables the observer can alter include:
-The demand for each type of dish
-The supply of each dish
-The chance that customers will be generated (essentially customer rate)
-The speed of the conveyor belt
-The speed at which the model runs

Additionally there are options to:
-Turn reflexive supply of dishes on/off
-Open/Close the restaurant entrance
-Turn labels of the chefs or customers on/off

Various monitors and plots allow the user to see the result of these dynamics such as:
-The total number of customers
-The number of free seats
-the number of instances of each type of dish
-A chart plotting the number of customers served every 100 ticks
-A chart plotting the number of angry customers every 100 ticks
-An average of the number of customers served (smoothed over 10 values)
-An average of the number of angry customers (smoothed over 10 values)

The observer can experiment with altering the different interface values and seeing the result both through the monitors and charts, but also the visual phenomena that develop such as bottlenecks, queues, the spatial distribution of angry customers etc.

THINGS TO NOTICE

Look out for emergent spatial phenomena related to complexity theory such as:
-queuing at the entrance to the restaurant
-bottlenecks within the kitchen and at the exit
-congestion on the conveyor belt
-notice how probability is inherent in every aspect of the model:
Agents don't always move in exactly the same way
Demand and supply of different dishes vary naturally
Customer population and restaurant performance can vary over time

Additionally look out for feedback loops:
-what happens if the supply values is not automatically altered?
-how does what happens in one system within the model affect the functioning of other systems?
-how does the feedback loop of customers becoming angry and leaving effect the dynamics of the model?

Finally notice the restaurant system itself:
-does the system function efficiently
-which seats are more likely to produce angry customers
-how does changing the variables affect the number of served/angry customers

THINGS TO TRY

-Try creating a setup which can serve the most amount of people
-Try creating a setup which minimises the number of angry customers
Repeat these processes but for different demand values for the dishes
-Try and control the model by manually changing the supply values of different dishes and manually closing the restaurant entrance. Can you create a more efficient system than the automatic balancing?
-Try and find out if too many chefs spoil the sushi
-Try altering the belt speed. Does it have a significant effect on the whole system? Is the degree of its influence what you expected?

EXTENDING THE MODEL

Pricing:
Probably the one key element missing from this restaurant system is a pricing model. There is no penalty for having additional chefs whereas in reality businesses need to consider salary as well as service.
Implement a pricing model for the different dishes enabling higher level dynamic between cost, service, efficiency etc. This could be further extended by having customers more/less likely to order expensive items etc. Tips could be included for faster service.

Happiness:
Implement a happiness variable for the customer agent, different customers could begin with different levels of happiness, this could then be influenced by queuing time, food efficiency and pricing. This could be implemented reflexively with higher levels of happiness influencing the number of customers that arrive.

Time:
Modify the variables for eating time, waiting tolerance, preparation time etc; see how this affects the overall model.
Adapt the model so that the various speeds of processes are more similar to real life.
Implement a 'Day' where the model runs for a set number of ticks, customer numbers could vary over this period. E.g. fewer customers in the morning, with surges at lunch time and dinner. This would make the model more true to life

NETLOGO FEATURES

In general Netlogo was a very useful system for creating this type of complex agent-based model.

However the key limitation was movement. Specifically creating a realistic system where agents move with a purpose and destination, however maintaining an element of randomness. Additionally there are limitations with allowing agents to move dynamically in a patch-based environment e.g. moving half a patch, or diagonally moving through the corner of a patch but never truly interacting with it.

To overcome these problems an entirely new system of movement was designed which fitted better with the patch-based world of Netlogo. Agents were allowed to move patch-by-patch vertically and horizontally, no turning was involved. The details of this system are documented along with the code at the bottom of the procedures tab.

RELATED MODELS

This geospatial model is far less abstract then most and therefore very few models truly relate. It was developed entirely from scratch, using completely original code.

Some inspiration was drawn from Gemma Polmear's model of supermarket dynamics.

CREDITS AND REFERENCES

As mentioned all code within this model are completely original.

The model was created by David Miller, an MSc student at Nottingham University studying Geographical Information Science.